外层 用的是  langgraph.graph.StateGraph ,边硬编码。这层的拓扑不依赖 LLM 决策,callback 是必经节点 —— 保证 RPC 回调一定触发。
中层 的  Host Agent  通过  build_domain_agent_v3(blueprint, resources)  构建。Blueprint 是声明式配置:
blueprint = AgentBlueprint(     agent_id=DIPG_AGENT_ID,                 # Host Agent 的唯一标识     instructions=_prompt,                   # 三阶段闭环 prompt     tools=[],                               # Host 默认加载了 DeepAgents 虚拟文件系统工具     subagents=[                             # 挂上另两个 Agent          await  get_chacha_research_sub_agent(...),    # Research Agent          await  build_chacha_verify_agent(),           # Verify Agent     ],     state_schema=ExtendedAgentState, )
底层基于 LangGraph 的  create_react_agent ,所以 Host Agent 本身就是一个 ReAct 循环 —— LLM 决策是否调工具、调哪个,直到模型主动停止调工具。
"DeepAgent" 是什么? deepagents  是 LangChain 团队维护的开源库( langchain-ai/deepagents )。我在其上做了模型选择、Checkpointer 注入、MCP 工具加载、audit 自动审计记录这些运行时装配。
内层 的  Research Agent  和  Verify Agent  都是  CompiledSubAgent ,各自是独立编译好的 LangGraph 图:
Research Agent 内部也是一个完整的 DeepAgent  —— 拥有自己的 ReAct 循环 + 工具链 + 中间件栈
Verify Agent 内部是一个两节点串行的 StateGraph  ——  structural_check → llm_verify  （HelixVerify 的简化版）
** 3.2 SubAgent 是怎么被注入给 Host Agent 的? 
—— task 工具 **
LangGraph 里没有"直接调另一个 agent"这种原生操作,所有异构执行必须包装成 工具 。 create_task_tool  做的事:
把 Research Agent 和 Verify Agent 按 name 注册到  agents  字典
创建一个  task(description, subagent_type)  工具
把  task  工具加到 Host Agent 的工具列表
Host Agent 的 LLM 看到的是这样一个 多态工具 :
task ( description : str,  subagent_type : str)   ├── subagent_type= "chacha_research_agent" : 专业的保险产品研究助手...(即 Research Agent)   └── subagent_type= "verify_agent" :          有任何报告验证的工作都交给我...(即 Verify Agent)
这个设计有两个关键后果:
Host Agent 不需要为每个 SubAgent 单独实现调用代码,加新 SubAgent 只需要在 blueprint 里多挂一个
Host Agent 的 LLM 天然用"调工具"的心智模型去编排另两个 Agent —— prompt 里告诉它"阶段 2 把报告交给 Verify Agent",它就知道调  task(description, "verify_agent")
** 3.3 Agent 间事件触发: 
task 工具内部做了什么 **
当 Host Agent 的 LLM 决策调  task("研究 prodNo=xxx...", "chacha_research_agent")  时,LangGraph 把调用路由到  handle_langgraph_sub_agent ,它做三件事:
上下文隔离 :每次调用都用新 thread_id + 全新 messages,SubAgent 看不到 Host Agent 的对话历史,也看不到兄弟 SubAgent 之前跑过什么。避免 Verify Agent 被 Research Agent 的"我觉得这段挺好"之类的自述污染。
单一返回值 :Host Agent 只收到一条  ToolMessage ,SubAgent 内部的多轮工具调用、中间推理对它不可见。这保证 Host Agent 的 context 不会被 SubAgent 的细节炸穿。
files 合并 :SubAgent 写的  state["files"]  通过  Command.update  合并回 Host Agent 的  state["files"] 。这是跨 SubAgent 共享数据的主通道。
多 Agent 的时序编排由 Host Agent 的 LLM 自己完成 ,不是代码写死的:

Host Agent 拿到 fix_hint 后 不会再派 Research Agent ,而是自己用  edit_file  /  write_file  工具直接在  state["files"]["report.html"]  上做局部编辑。
换句话说, 这个 verify-修正闭环不是硬编码的 Graph 边,而是 prompt 层约束下的行为契约  —— 它完全由 Host Agent 按指令驱动,循环多少轮、什么时候停,是 Host Agent 自己根据 Verify Agent 的反馈判断的。
** 3.4 Research Agent 的工具链 + ReAct **
"深度搜索"不是独立的 agent,而是  Research Agent  自己作为 ReAct agent 多轮调工具逐步收集信息。它的工具集只有三类:
sub_agent_tools  = [     download_insurance_product_materials,   # 按 产品 拉取素材     read_disk_file,                          # 读具体素材文件     web_search,                              # 必要时网络检索 ]
通常来说，Research Agent 会尝试:
LLM 读  chacha_prompt  里的   章节,明确要分析的维度
调  download_insurance_product_materials  —— 返回素材到磁盘中与素材地图,形如  {"CLAUSE": [...], "INSURE_NOTICE": [...], "HEALTH_INFORM": [...]}
LLM 串联多次  read_disk_file(path)  —— 逐个读条款、投保须知、健康告知
条款里缺的数据(如行业发病率),LLM 调  web_search(query)  补充
所有信息收齐后,LLM 进入"页面生成阶段",产出 HTML
这个过程由 LLM 自主决策,没有固定编排。chacha_prompt 控制:
 告诉 LLM 素材类型和工具能力
 明确"阶段一:工具调用" vs "阶段二:页面生成"不得混用
** 3.5 HTML 产出:写进 state["files"] 
作为跨 Agent 记忆 **
Research Agent 的 instructions 末尾被强制追加:
instructions  =  prompt  +  (      " \n !!!IMPORTANT: 你交付的 HTML 文件必须是 HTML 组件, 以

位置
写入者
读取者
生命周期
state["files"]
LangGraph state(内存中的虚拟文件系统)
write_file  工具 via  Command.update
任何能访问 state 的 SubAgent
随 checkpointer 持久化
/audit/
虚拟文件系统 ( workspace/audit_logs/ )
AuditWrapperMiddleware (包装所有工具调用)
Verify Agent 通过  read_file  读取state["files"]["audit"]
随 checkpointer 持久化
files  = 生成的 产物 (HTML、中间结果)
/audit/  = 生成的 原料 (工具调用的输入输出)
Verify Agent 用  ls /audit/  +  read_file  组合就能读到 Research Agent 期间的全部工具调用记录。
Verify Agent 两者都要看 ——  产物 vs 原料做对齐 ,才能判忠实性。
四、Research Agent 的 prompt 契约:
让它一次过
进入离线 verify 闭环之前,先讲注入给  Research Agent  的 prompt。这部分规则同时服务两件事:
离线链路 : Research Agent 一次过的质量越高,Verify Agent 需要返回的修正意见就越少,verify-修正闭环收敛得更快,计算成本更低。
实时链路 (兜底): 没有 Verify Agent 兜底时,prompt 的约束强度基本等于交付质量的上限。
** 4.1 合规用语硬规则(监管红线) **
- 禁止:  "0免赔""零免赔""无免赔"    → 合规:  "0免赔额""免赔额为0" - 禁止:  "100%全赔""多少都能赔"     → 合规:  "责任内,赔付比例100%" - 禁止:  "储蓄险"                   → 合规:  "储蓄型保险" - 禁止:  "确诊即赔"                 → 合规:  "首次确诊责任内疾病可赔" ...
监管敏感词, 绝不允许出现 ,硬约束清单。
** 4.2 事实性保证的 8 条规则 **
针对幻觉问题,prompt 里明确了 8 条事实性保证规则(节选):
信源优先级 :产品档案 > 保险条款 > 网络搜索 > 通用知识
无数据不展示 :缺失字段直接隐藏,不做任何臆测
图表真实性 :单点数据不准画趋势图,降级为数字卡片
禁止盲目对比 :没有竞品数据不得使用"优于市场 85%"(第二节那个惠民保 badcase 的直接教训)
否定约束 : is_state_owned: false  就严禁出现"国企/央企"
其中最有意思的是 强制前置溯源 :
利用模型自回归特性,在生成任何关键数据之前,先生成 HTML 注释说明数据来源。格式  

** 5.2 Verify Agent 内部:程序化 + LLM **
Verify Agent  由两节点子图组成:

structural_check(程序化校验)  —— 纯 Python,基于  html.parser.HTMLParser  自定义的  StructureParser ,检查若干条确定性规则:
规则编号
检查内容
rule1